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Abstract — With recent advances in graphical user interfaces, 
more and more tasks on computers have become easier to 
perform. Out of the belief that creating computer programs can 
also be one of them, visual programming languages (VPLs) have 
emerged. The goal of VPLs is to shift a part of work from 
the programmer to the IDE so that the programmer can focus 
more on algorithm logic than the syntax of the implementation 
programming language. In this article, the methods required to 
build a VPL are presented, with an emphasis on a novel method 
of code generation in a WHILE language. Also, the methods for 
achieving basic principles of VPLs will be shown - suitable visual 
presentation of information and guiding the programmer in the 
right direction using constraints. 

These methods are demonstrated on an example of vIDE, a 
VPL based on the Eclipse integrated development environment 
(IDE). The design of vIDE with respect to the Eclipse Graphical 
Modeling Framework (GMF) is described. The concept of a 
flowchart graphical notation is examined in contrast with the 
algorithm model it maps to. Finally, the disambiguity of the model 
representation of an algorithm is discussed and the methods for 
transforming it to an actual implementation in a programming 
language. 

Index Terms — Visual programming, VPL, GUI, flowchart, al- 
gorithm, model, programming language, GOTO, WHILE, vIDE, 
Eclipse, GMF, OCL, Python. 

I. Introduction 

As desktop computers become more and more powerful, 
we see a big improvement in the quality of graphical user 
interfaces (GUIs). What about programming? Can the classical 
textual programming language environments be replaced with 
more modern graphical applications? There are few key points 
in discussing positive aspects of developing VPLs. 

A. The strengths of visual programming 

According to its definition in (TJ, an algorithm has five 
important features: finiteness, definiteness, input, output and 
effectiveness. The most important feature we will examine in 
this context is definiteness - the steps of an algorithm have 
to be well defined, disambiguous. We can infer from this that 
to implement an algorithm, a computer program also requires 
definiteness. 

In classical programming languages (such as C, defined in 
[2 1) the programmer writes his program down in a textual file, 
compiles it to machine code and is able to execute it. Textual 
files can consist of any imaginable text - from Shakespeare's 



dramas to random gibberish. Well defined classical programs 
are a very small subset of text. In classical programming lan- 
guages, definiteness is checked mostly through programming 
language syntax (it is also achieved in part through semantic 
and dynamical checks at later stages of program compiling 
and running, but that won't be discussed here). Syntax is 
essentially a set of rules that constraint text that qualifies as 
valid - more details can be found in 13. The programmer 
tries to describe an algorithm he has imagined by writing 
commands in some syntax and getting notifications about their 
correctness afterwards. This is in its essence a very black- 
box approach, i.e. the programmer receives only a posteriori 
notifications about the program's definiteness. Of course, there 
are some features that help in the process, like dynamic type 
checking or auto-completion which save time, but they do not 
let the programmer fully forget about the syntax. 

In VPLs the programmer doesn't input text, but uses mod- 
ern GUI capabilities to drag & drop blocks of commands, 
connections between them etc. to describe an algorithm. This 
is by itself a reduction of the possible constructs that can be 
made by a programmer - only a couple of symbols (defined by 
the language designer) are available, in contrast to the whole 
alphabet (and more) in classical programming. The choices 
a programmer has to make when defining programs are 
limited to the ones that satisfy the language syntax only. An 
illustrative way to describe this would be to say that in VPLs 
the keyboard has been sawed off to contain only the keys vital 
to programming (sort of like the old Spectrum computers). 
Another important aspect is the chance for preeminent 
notifications - notifying the programmer about the possible 
constraint breeches (syntactic or semantic errors) while he 
is still dragging an element in the GUI - possibly saving 
the time of making a mistake. This way a programmer is 
guided to satisfy constraints as proposed in [4], unlike syntax 
errors which just notify the user when he's already breeched 
one. Finally there is the visual overview aspect - unlike 
classical programs where we have to first focus on specific 
letters and read them to discover what type of algorithm 
pattern we're dealing with, in visual programming we have 
the ability to recognize certain patterns in a purely visual way 
(by recognizing circles, squares, lines, colour etc.), leading to 
an examination of the meaning of some program in a more 
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Fig. 1 . A diagram showing the distribution of work between the programmer and the IDE in visual programming 



top-down manner. 

All in all, an attempt is made in VPLs to shift more of the 
work from the programmer to the IDE. As illustrated in 
Fig. [T] the task of syntax generation is done automatically - 
allowing the programmer to focus more on the abstract notions 
of algorithm design. 

To summarize, the benefits of this shift are: 

• easy syntax rule obeying - only the freedom of creating 
programs is given to the programmer 

• a better notification system - due to the fact that the 
IDE has more knowledge about the program and the 
programmer's actions at an earlier moment than classical 
programming IDE 

. visual representation can be easier to grasp 

B. Related work 

In a general overview of the visual programming 
strengths and weaknesses is examined with a lot of examples 
of how certain languages cope with these opportunities and 
challenges. The two most notable items proposed are: 

• static representation - is a graphical notation used to 
present a program at rest sufficient to understand the logic 

• effective use of computer display - showing only the 
information important to the user at any given time 

Lab View and Simulink can be mentioned as the represen- 
tatives of a big group - the data flow VPLs, described in 0, 
which are based around a functional programming style. A 
similar VPL, but presented as an online web service is Yahoo 
Pipes 0| . 

KTechlab [7| is a flowchart VPL used to describe hardware 
components. Scratch (8] is a good example of a WHILE 
language flowchart VPL that has taken the role of education 
through fun and interactive app programming. One drawback 
in Scratch is that it doesn't present the user with the source 
code generated from his flowchart, thus not encouraging 
gradual transition to classical programming as the user gets 
more experienced. 

C. Goals 

The goal of this paper is to present the methods required 
to create a VPL for editing and executing flowcharts with an 
additional ability to generate classical source code from them. 
This would give the user another educational step between 
Scratch and classical programming, where he would be able 



to draw a flowchart and generate good quality, readable code 
from it and execute it. The code readability would let him 
study and understand the syntax created from his flowcharts. 

These methods will be explained on an example of vIDE, 
a VPL that was built to fulfil the requirements. The motive 
behind vIDE is to lower the barrier of learning programming 
for children as well as for other experts who don't know a 
programming language syntax, but need to implement certain 
algorithms. 

Firstly, a flowchart editor is needed and the problem of 
synchronizing a graphical representation with a model will be 
addressed. Secondly, we will cover the problem of generating 
code in a certain classical programming language from this 
model. 

An interesting aspect of code generation that will be ex- 
plored is the internal representation of an algorithm in a 
GOTO manner, the most similar in logic to a flowchart, and 
its transformation to a WHILE language data structure. The 
GOTO and the WHILE languages are formally defined in J9). 
In short - the GOTO language uses a GOTO instruction to 
jump anywhere in the program, while the WHILE language 
has WHILE and IF instructions to conditionally execute a 
certain block (zero, one or multiple times) thus adding more 
structure and making the flow more predictable. It will be 
shown that the transformation from a GOTO language to a 
WHILE language representation is a very practical way of 
building a flowchart VPL because of the difference between a 
VPL conceptual model and an output classical programming 
language. 

D. Organisation of the paper 

In section|Il]the methods used to create a VPL are presented. 
In |II-A| a system architecture of vIDE will be explained so 
that certain modules can be referenced later in a more clear 
way. The problem of diagram-to-model mapping is discussed 
in lll-BI The motives and mechanics behind GOTO-to- WHILE 
model-to-model transformation used in vIDE is given in |II-C| 
Finally, the last step of generating code is shortly explained 
in llLDl 



In section III we examine the capabilities of vIDE - a simple 
example of usage, the special cases of constraint satisfaction 
and a useful feature of knowledge inferring from the model. 



Section IV places the achieved results in the context of 
related work and the initial objectives and summarizes the 
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Fig. 2. A graphical overview of the vIDE system architecture 



advantages of the used techniques and possible improvements. 
II. Methods 

In order to be fully usable as a programming language, a 
VPL must allow the programmer to: 

• express an algorithm's logic in some manner and 

• be able to translate this logic into executable machine 
instructions 

Next, the methods used in implementing our VPL, vIDE, 
to achieve this will be analyzed. 

A. System Architecture 

The system architecture of vIDE, the VPL used as an 
example VPL in this paper, is illustrated in Fig. [2] 

In a very general sense vIDE achieves the basic program- 
ming language functions through: 

• a flowchart editor - where the programmer visually 
defines his logic 

• a launcher (a compiler of sorts) - which transforms the 
user's flowchart into source code that can be executed 

The first step to achieve this is to allow the user to 
draw a flowchart. This was implemented using the GMF, a 
framework for creating diagram editors. As seen in Fig. [2] 
an algorithm model is kept in sync with the flowchart that 
the user draws. GMF does this automatically according to a 
predefined mapping model). Further information about GMF 
can be found in iflOl . 

The flowchart can be launched through the GUI when the 
user is happy with it. This action initiates a transformation 
of the algorithm model represented in a GOTO manner to 
an equivalent WHILE language style representation (this is 
required because a WHILE representation can't be created by 
GMF directly from the vIDE flowchart graphical notation - 
this will be further discussed in section [ILC| . 

From the WHILE language data structure, a concrete textual 
syntax can easily generate code in any programming language 
that relies on WHILE and IF commands to control data flow 
(for example C [2| or Python ifTTI '). In vIDE, a Python syntaxer 
module is called to generate a Python script as the output 
program, equivalent to the user's flowchart. 

Once the output program is generated, the user can study 
the source code to learn its syntax or simply run it and observe 
the effects of the flowchart he drew. 

In the next few sections the vital methods needed to create 
a VPL able to generate code will be examined using vIDE as 
an example implementation. 



B. The flowchart editor - mapping a diagram to a model 

In every VPL some sort of diagram editor is needed that 
can be map a graphical notation to a model. A flowchart editor 
in vIDE was created using GMF, which uses a nice abstract 
way of describing the diagram editor. In this part it doesn't 
really matter what sort of a diagram we're building (flowcharts 
are just special types of diagrams). The way GMF works 
is that it requires several models which define the diagram 
editor's behaviour. Using these models, the diagram editor 
Eclipse plug-in can then be generated. Methods for building 
the flowchart editor will be given here in relation to the GMF 
architecture, but these or similar modules would be required 
when creating a diagram editor utilizing any other technology 
as well. 

The models needed to create a diagram editor, that is, their 
implementations for vIDE through GMF are: 

• A graphical definition - describing the graphical ele- 
ments that the user will see in his diagram; in vIDE that 
would be the block, branch and connection elements. 

• A tooling definition - definitions of available tools for 
drawing the diagram; one tool is defined in vIDE for 
every graphical element. 

• An Eclipse Modelling Framework (EMF) model - this 
is basically the goal data structure synchronized with the 
diagram as the user edits it; in vIDE a simple GOTO-like 
algorithm data structure is used and its class diagram can 
be seen in Fig. [3] 

• A mapping model - this is the heart of the diagram 
editor description, it defines how to map elements from 
the graphical definition to an EMF model and GMF 
uses this definition to synchronize the diagram and the 
model automatically; if an algorithm model uses a GOTO 
representation (as is the case in vIDE), this mapping is 
pretty straightforward - a block element maps to a block 
class, branch to branch etc. 

C. An algorithm for GOTO to WHILE transformation 

After an algorithm model has been created, a program 
could be generated disambiguously. The problem is that the 
algorithm model is described in a GOTO language manner 
and we want to generate a program in a WHILE language. 
To achieve this, a transformation is necessary. First, we will 
examine the motives for organizing the data structures in 
such way that the transformation is necessary and then the 
transformation algorithm itself. 




Fig. 3. Algorithm EMF model used in vIDE - a GOTO-like data structure 
generated from the flowchart 



1 ) Reasons for using a GOTO language: For a represen- 
tation of algorithms in flowcharts, a GOTO language seems 
more natural, because of a single connection (or we might say 
flow) going out of every block. 

Other possible graphical representations were explored - 
with special graphical elements for WHILE and IF commands, 
but these approaches were dropped, because there would have 
to be multiple outgoing flows and additional explanation of 
these elements' behaviour would be necessary, which would 
complicate the usage of vIDE. 

2) Reasons for NOT using a GOTO language: It was 
explained in the last subsection that GOTO is a suitable 
language for the graphical representation of an algorithm. For 
the generated programs, on the other hand, WHILE-languages 
should generally be used instead. 

In his open letter, Dijkstra expressed his opinion against 
using GOTO instructions in programming 1121 . while Knuth 
said in ifPSll that they can be useful at times. Generally, we 
can conclude that GOTO commands can be used carefully 
(an example of proper usage of GOTO commands in mod- 
ern languages are exceptions), but WHILE, IF and similar 
commands should be used to create structured programs. 
Structured programs are defined in lfl3l . 

One of the good sides of structured programming is read- 
ability - if a programmer wants to see what was generated 
from his flowchart, it would be much more readable (not to 
mention educational) if loops would be interpreted as WHILE 
commands and normal branches as IF commands (instead of 
everything mapping to simple GOTO commands). 

A WHILE language representation of the flowchart might 
be useful to have in a data structure for visual purposes as well, 
because the usage of structured programming would allow 
features such as graph folding (letting the programmer hide 
unnecessary nodes manually or let the IDE do it for him using 
context-aware technologies such as [14|). 

Python was chosen for an output programming language in 
vIDE because of its simplicity and readability, so another prac- 



tical reason for not generating code using GOTO commands in 
vIDE in specific is that Python doesn't have a GOTO command 
in its language. 

3) Combining the two - the constrained GOTO: When a 
pure GOTO language representation of an algorithm is stored 
in a data structure it is clearly a graph - it can contain loops to 
already executed commands. When an algorithm represented 
in a structured WHILE programming language is stored it is 
possible to represent it by a tree - an intuitive example of 
this is the ability to fold code in environments such as Eclipse 
ifTSIl . The reason this is possible is that the body of a WHILE 
loop or an IF body can't jump to any other instruction outside 
its parent WHILE/IF instruction. Even though it's possible to 
model WHILEs and IFs using GOTO commands, the GOTO 
would also allow "forbidden jumps" (for example to the same 
command), therefore necessitating a graph data structure for 
the algorithm's representation. 

Since graphs can't generally be represented by trees, to 
be able to transform a GOTO representation to a WHILE 
representation, constraints have been introduced in vIDE on 
the flowcharts that can be drawn in it: 

• loops can only be drawn to go back to the last branch 
predecessor (of the same branching depth) 

• if a branch is not a loop its children blocks must join at 
one point (they need to share a common successor) on 
the same branching depth 

Using these two constraints we effectively mask a WHILE 
language using a GOTO language, without the fear of not 
being able to convert it to a tree representation. 

4) The transformation algorithm: Once we set the con- 
straints, we can define an algorithm for transforming a con- 
strained GOTO algorithm (illustrated in Fig. [3} into a WHILE 
algorithm. 

The GOTO-to- WHILE algorithm is essentially a depth first 
search (DFS) that recursively processes the nodes of a GOTO 
algorithm collecting single instructions to blocks and trans- 
lating branches to WHILE or IF commands using processed 
node "colouring" (see |[T6l for DFS and similar graph traversal 
algorithms). 

This is the basic idea of the algorithm (meant to be called as 
G2W(instruction), where the first instruction of the main block 
of the algorithm should be provided to the initial function call): 
while instruction exists do 
if instruction's a block then 

nothing special 
end if 

if instruction's a branch then 

trueChild <— true child of the branch 

if G2W(trueChild) found processed command then 

translate instruction to WHILE 
end if 

if G2W(trueChild) reached program end then 

translate instruction to IF 
end if 
end if 



-i- print "Greatest common divisor is:™ 












: print n 






Fig. 4. A flowchart of the Euclid's algorithm drawn in vIDE 

mark instruction processed 
instruction next instruction 
end while 

Note that G2W(trueChild) represents processing child in- 
structions of a branch in the case of the condition being met - 
going further in depth recursively on the true side. Also, this 
is only a sketch of the "interesting" parts of the algorithm. In 
an actual implementation: 

• All the constraints need to be checked and any breeches 
communicated to the user. 

• Also, resolving the IF transformation is a bit more 
complex and requires tracing the condition being false 
branch as well and fixing the tree afterwards (because 
at first all the successor instructions would be added to 
IF as children - an intersection, i.e. the end of the IF 
instruction, can only be found after tracing the second 
branch - false). 

• The last omitted aspect is the communication - a lot of 
information needs to be passed as arguments to recursive 
function calls or using a stack to identify the true state 
of the graph. 

These details were skipped, since they would complicate the 
pseudo-code a lot and they can be implemented quite routinely. 

D. Model-to-code transformation 

After we have the algorithm represented in a tree-like 
structure of a structured WHILE language, the code generation 
is very simple and consists of: 

1) a DFS through the tree 

2) translating instruction objects to strings in the goal 
language syntax (Python in vIDE's example) on a one- 
to-one mapping basis. 

III. Results 

As a result of implementing all the presented methods, vIDE 
was built - a VPL that can be installed as an Eclipse plug-in 



and used to draw flowcharts and generate Python code from 
them. In this section its capabilities will be examined. 

A. An example of vIDE usage - code generation 

The example of the Euclid's algorithm drawn as a flowchart 
in vIDE is shown in Fig. [4] From this flowchart the user can 
launch the code generation and a Python script is generated, 
equivalent to the algorithm defined in the flowchart: 

m=6 
n=2 

r = m % n 
while r != 0: 

m = n 

n = r 

r = m % n 
print "Greatest ^common^ divisor^is : " 
print n 

The branch in the flowchart was recognized by the GOTO- 
to-WHILE transformation algorithm to be a loop (because 
an instruction was pointing to its predecessor; note that a 
constraint wasn't breeched because it is the last branch) so 
a WHILE instruction in Python was generated. 

B. Constraint satisfaction in vIDE 

An example of automatic constraint satisfaction checking is 
implemented in vIDE, so that the user is not allowed to make 
a mistake in the first place. For example the user can't connect 
a block to itself (a circular connection - it would result in an 
infinite loop), because the environment won't let him "drop" 
a connection on that position. This was implemented using 
the Object Constraint Language (OCL) ifTTI . a language for 
constraint definition which is integrated with GMF in a way 
that the checks are done in real time - presenting the user 
with the currently relevant information. 



The constraints defined in section II-C3 i will notify the user 
about a constraint breech only when he launches the flowchart- 
to-code transformation. This wasn't implemented in OCL, but 
in Java (because the check requires recursive function calls, 
which to our knowledge isn't possible in OCL), as a part of the 
GOTO-to- WHILE transformation, so the notifications aren't 
real-time. 

C. Knowledge inferring in vIDE 

One of the nice features of GMF is that it infers knowledge 
from the EMF model created to describe the diagram editor. 

An example in vIDE is that creating a connection from a 
branch for the first time asks the user whether it is the true 
or the false case, but when a true case is already present, the 
system deduces that there is no need in show this choice to 
the user as seen in Figure [5] resulting in only the semantically 
relevant information presented. 
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Fig. 5. Connection creation wth deduction (excess choices are trimmed) 



IV. Conclusion 

The proposed methods for building a VPL capable of 
flowchart editing and code generation have been shown to 
work on the example of vIDE. The VPL can be used for 
drawing and executing flowcharts comparable to [8|, while 
also giving the user the novel ability of generating clear, 



readable Python code, achieving the goals set in I-C This 
is important, because it allows the users to more easily grasp 
programming language syntax and move to more complex, 
classical programming later (if needed). Such an application 
could find a lot of use in lowering the programming entry 
barrier and would be important for: 

• didactic purposes - teaching programming in an interac- 
tive and visual way 

• ease of usage - making programming more accessible to 
people of other professions 



Features such as knowledge inferring, described in III-C 



provide a great way of leveraging advanced GUI capabilities 
to provide a better programming environment. This goes in 
line with the general guidelines for creating VPLs stated in [4] 
and could be considered as a visual programming equivalent 
of context aware systems such as Mylyn lfl4ll . 

Constraint definition using OCL enables real-time notifica- 
tions. This seems to be a good way to utilize the advantages 
of VPLs - namely a chance for preeminent notifications, 



as described in I-A One of the problems is checking more 
complex constraints. Perhaps iterative transformation to the 
WHILE language model while the flowchart is being drawn 
would allow for more lively notifications. 
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